Telecommunications systems need to process the data flowing through them in complex ways, often with processing occurring on computer systems separated both geographically and administratively. Many communications paths are simultaneously active, and the processing applied to the various flows of data changes frequently and in a wide variety of ways. The software needed to control these computer systems is generally large, complex and difficult to change.
When the data flowing through the system represents voice, such as in a modern digital telephone network, special processing must be applied to implement such features as three-way or multi-way calling, voice-mail, voice recognition and authentication, call waiting, encryption, voice coding and dual-tone multi-frequency (DTMF) detection. For data applications in general, such as electronic mail, remote computing, file transfer between computers or Web browsing, there are needs for security functions such as firewalls and encryption as well as datastream functions such as traffic shaping, error handling, prioritization, caching, format translation and multicast.
While telecommunications systems are already complex, this is a market for new services such as video telephony, Internet games, video on demand, Internet audio, remote collaborative work and telemedicine. These services will need new families of features to be overlaid on the existing network, making the software development task even more complex.
As well, even for a single application, different users may have different needs, for example, requiring different degrees or forms of encryption. This makes the development of communications applications slow due to the complexity of handling many cases.
In addition to their different processing and connectivity requirements, different telecommunications applications have different needs for “quality of service” measures such as delay time, delay variability, and reliability. These requirements ar not presently specified in a flexible manner, though they may vary for different parts of a complex telecommunications application. For example, if a voice-mail system is used to record a voice call between two parties, low delay is important between the human parties but not in the path to the voice mail's storage location.
In addition to specifying the behaviour and quality of service that the application desires from the telecommunications system, optimal use of the telephone system's resources requires it to describe the loads that it will place on that system, for example in terms of bandwidth requirements on communications links and in terms of processing power required in computation nodes. Current systems do not have this capacity.
The complexity of present telecommunications systems software, and the extensive interactions between its software components, makes the development of new features very difficult. As well, telecommunications services have traditionally been provided by large monopolies who employed proprietary equipment that only they had access to. Another complexity is that new services had to be backward compatible to handle their existing clientel.
Software development is therefore limited to a “closed group of trusted developers, which reduces the talent pool available and shuts out developers with new ideas for niche markets.
Traditional telecommunications do not consider differentiation, but only a single service. Therefore, telecommunications providers would not be encouraged to offer varied services at a cost reduction to users, for example, reduced quality of voice telephony on Christmas Day, simply to provide additional connections or reduced cost.
As well, small niche markets have gone completely unserved as the cost of developing and implementing the additional products does not net sufficient profits.
Telephony systems as currently implemented comprise “switches” controlled by large computer programs and interconnected by a variety of means, such as optical fibre and coaxial cables. These systems also include computing means to implement such features as conference calling and voice mail. Telephony features, such as voice mail and call forwarding, are implemented by adding code to the programs running the switches and by adding specialized hardware to the telephony network. The features available to particular users are defined in databases accessed by the switch software, and adding a new type of feature may involve changing these databases together with all of the switch software that uses them, and may also involve purchasing and installing new types of hardware in the network. Specialized software is also used to check the consistency of the features assigned to a particular user, for example, call-waiting and call-forward-on-busy features define different behaviours for the same event, in this example a busy receiver.
Changes to the existing telecommunication networks are therefore very complicated to make. There is a rigid model and the hardware structure is difficult to extend. Therefore, existing telephone companies can not easily offer new features such as high quality voice. As well, existing telephone companies take a long time to bring such features to market.
Users can exercise a small degree of control over their telecommunications by use of software running on their personal computers (PCs). For example, there is currently a Telephony applications programming interface (TAPI) that allows software running on a general-purpose computer to control the switching decisions of a type of switch known as a private branch exchange (PBX). An application programming interface (API) converts a series of comparatively simple and high level functions into the lower level instructions necessary to execute those functions, simplifying control of an operating system. Using Windows™ APIs, for example, a program can open windows, files, and message boxes, as well as perform more complicated tasks, by executing a single instruction. Windows™ has several classes of APIs that deal with telephony, messaging, and other issues.
TAPI consists of a large collection of specialized subroutine calls that allow a user to set up and tear down circuits connecting particular physical devices, including telephone sets and servers for functions such as voice-mail. It also allows the user to define how the system should respond to events such as hangups.
A system known as Parlay™, developed by a consortium of companies, implements a telephony API that can be used to control the central office telephone switches owned by large telephone companies. This is similar in concept to the use of a telephony API to control a PBX, but security concerns are of prime concern because of the number of telephone users who would be inconvenienced by a failure.
Parlay™, TAPI, J-TAPI (a Java version of TAPI) and similar systems permit third parties a degree of control over how telephone switches interconnect end users and specialized equipment such as voice-conferencing servers, but do not allow third parties to add new features such as encryption or voice coding. They are also unable to describe the handling of Internet traffic, and so it is necessary for a distinct system to be used to handle such functions as routing Internet browsing data through computers acting as security firewalls.
Socket mechanisms are widely used to describe connections between applications programs running on operating systems such as UNIX™ and Windows™. It can be used to set up connections between applications programs running on different computers, such that packets of data are passed between them across such networks as an Ethernet or the Internet.
When using a socket to communicate with a process on another computer, the programmer defines one side of a communication but must rely on the administrators of the other computer to have set up the other side. A port number is used by convention to describe the expected functionality of the program.
There is therefore a need for a method and system of providing telecommunication services that are flexible and efficient, and improve upon the problems described above. This design must be provided with consideration for ease of implementation and recognize the pervasiveness of existing infrastructure.
WO 97/36430 to Robart et al. relates to Service Provisioning in Intelligent Networks. Specifically, Robart teaches a “Service Logic Representation” (SLR) which is used to translate a defined telecommunication feature to run on special purpose hardware (an Execution Environment) built by various vendors and which have different interfaces and/or hardware. The SLR is a defined high level description of the telecommunication feature and each vendor's Execution Environment translates the SLR into its own required format or expression.
The problem addressed by Robart is the need to execute predefined telecommunication features for execution on hardware built by different (non-compatible) vendors. As admitted in Robart, this was previously solved by using appropriate cross compilers for each execution environment and the solution of Robart is to define a standard representation for such features and to ensure that each vendor's Execution Environment can interpret the standard representation. In contrast, the present invention teaches a system and method wherein telecommunication connections and/or features are proposed, at call set-up time, by the calling party (user) through a proposed desired communication, which is defined as a proposed graph. The network examines the proposed graph to correct/augment the proposed graph to obtain an executable graph and then transmits the executable graph to the network devices to implement the desired communication.
The problem addressed by the present invention, is to provide for a telecommunication system which allows for the flexible set-up of connections/features which need not be predefined, nor static once established. This is accomplished by the user defining a data structure representation of a proposed connection or feature and submitting the representation of the proposed connection or feature to the network. The network then corrects and/or augments the proposed connection or feature as necessary to obtain an executable representation of the connection or feature and the network distributes this executable representation to the network devices required to implement the connection or feature. The network devices then examine the representation and perform their necessary activities to implement the connection or feature. Any device which does not have the software for a necessary function can obtain that software through the network. Once the connection or feature is established, the network can monitor it and create a new executable representation to address network device failures, network condition changes, etc. and the new executable representation can be transmitted to network devices and executed to adjust a connection or feature.